\chapter{Travail effectué}
% Le travail effectué [30 pages]
%    Étude du cahier des charges
%    Propositions et critiques de solutions
%    Description complète de la solution choisie
%    Mise en oeuvre
%    Résultats obtenus (critique)
Le travail effectué pendant le stage comporte :

\begin{itemize}
	\item Analyse des dossiers (les documents de l'\textit{ARJEL} et de \textit{Dictao}),
	\item L'étude des technologies utilisés (framework \textit{Web:Extend}, \textit{Javascript animate}, \textit{Taconite}),
	\item Assistance du chef du projet (gestion de comptes du serveur, formation des autres stagiaires),
	\item Dévéloppements et configurations du projet.
\end{itemize}

Ce chapitre est à but de présenter principalement les dévéloppements fait pour le projet en détaillant les solutions et les résultats.
\section{Configuration du \textit{Git}}
    \subsection{La problématique}
        \textit{Git} est un logiciel de gestion de versions puissant. Il supporte plusieurs façons de travail. L'objectif est de mettre en place ce système sur le serveur.
		
		Pour l'installer il faut choisir le protocole, la mode de gestionnaire et la façon de gestion de compte.
    \subsection{Propositions de solutions}
		\subsubsection{Protocoles}
			\textit{Git} peut utiliser quatre protocoles réseau majeurs pour transporter des données : local, Secure Shell (\textit{SSH}), \textit{Git} et \textit{HTTP}.
			
			Il est à noter que mis à part \textit{HTTP}, tous les protocoles nécessitent l'installation de \textit{Git} sur le serveur.
			
			\paragraph{Protocole local}
				Le protocole de base est le protocole local pour lequel le dépôt distant est un autre répertoire dans le système de fichier. Il est souvent utilisé si tous les membres de l'équipe ont accès à un répertoire partagé via \textit{NFS} par exemple ou dans le cas moins probable où tous les développeurs travaillent sur le même ordinateur. Ce dernier cas n'est pas optimum car tous les dépôts seraient hébergés de fait sur le même ordinateur, rendant ainsi toute défaillance catastrophique.
			
				\subparagraph{Avantages}
					Les avantages des dépôts accessibles sur le système de fichier sont qu'ils sont simples et qu'ils utilisent les permissions du système de fichier.
					
					C'est un choix satisfaisant pour partager rapidement le travail.
				\subparagraph{Inconvénients}

					Les inconvénients de cette méthode sont qu'il est généralement plus difficile de rendre disponible un partage réseau depuis de nombreux endroits que de simplement gérer des accès réseau.
					Il est aussi à mentionner que ce n'est pas nécessairement l'option la plus rapide à l'utilisation si un partage réseau est utilisé. Un dépôt local n'est rapide que si l'accès aux fichiers est rapide. Un dépôt accessible sur un montage \textit{NFS} est souvent plus lent qu'un dépôt accessible via \textit{SSH} sur le même serveur qui ferait tourner \textit{Git} avec un accès aux disques locaux.					
			\paragraph{Protocole \textit{SSH}}
				Le protocole \textit{SSH} est probablement le protocole de transport de \textit{Git} le plus utilisé. Cela est dû au fait que l'accès \textit{SSH} est déjà en place à de nombreux endroits et que si ce n'est pas le cas, cela reste très facile à faire. Cela est aussi dû au fait que \textit{SSH} est le seul protocole permettant facilement de lire et d'écrire à distance. Les deux autres protocoles réseau (\textit{HTTP} et \textit{Git}) sont généralement en lecture seule et s'ils peuvent être utiles pour la publication, le protocole \textit{SSH} est nécessaire pour les mises à jour de par ce qu'il permet l'écriture. \textit{SSH} est un protocole authentifié suffisamment répandu et sa mise en \oe{}uvre est simplifiée.
				\subparagraph{Avantages}
					Les avantages liés à l'utilisation de \textit{SSH} sont nombreux. Primo, nous ne pourrons pas faire autrement si nous souhaitons gérer un accès authentifié en écriture à notre dépôt au travers le réseau. Ensuite, l'accès distant à travers \textit{SSH} est sécurisé, toutes les données sont chiffrées et authentifiées. Enfin, comme les protocoles \textit{Git} et local, \textit{SSH} est efficace et permet de comprimer autant que possible les données avant de les transférer.
				\subparagraph{Inconvénients}
					Le point négatif avec \textit{SSH} est qu'il est impossible de proposer un accès anonyme au dépôt. Les accès sont régis par les permission \textit{SSH}, même pour un accès en lecture seule, ce qui s'oppose à une optique open-source.
			\paragraph{Protocole \textit{Git}}
				Vient ensuite le protocole \textit{Git}. Celui-ci est géré par un daemon spécial livré avec \textit{Git}. Ce démon écoute sur un port dédié et propose un service similaire au protocole \textit{SSH}, mais sans aucune sécurisation. Soit le dépôt \textit{Git} est disponible sans restriction en lecture, soit il n'est pas publié. Cela signifie qu'il ne permet de pousser des modifications. Autant dire que ce mode est rarement recherché.
				\subparagraph{Avantages}
					Le protocole \textit{Git} est le protocole le plus rapide. Il utilise le même mécanisme de transfert de données que \textit{SSH}, la surcharge du chiffrement et de l'authentification en moins.
				\subparagraph{Inconvénients}
					Le défaut du protocole \textit{Git} est le manque d'authentification. N'utiliser que le protocole \textit{Git} pour accéder à un projet n'est généralement pas suffisant. Il faut le coupler avec un accès \textit{SSH} pour quelques développeurs qui auront le droit de pousser (écrire) et le garder pour un accès en lecture seule. C'est aussi le protocole le plus difficile à mettre en place. Il doit être géré par son propre daemon qui est spécifique. Il nécessite aussi un accès à travers le pare-feu au port 9418 qui n'est pas un port ouvert en standard dans les pare-feux professionnels. Derrière les gros pare-feux professionnels, ce port obscur est tout simplement bloqué.
			\paragraph{Protocole \textit{HTTP/S}}
				Enfin, il reste le protocole \textit{HTTP}. La beauté d'\textit{HTTP} ou \textit{HTTPS} tient dans la simplicité à le mettre en place.
				
				Il est possible de faire pousser \textit{Git} à travers \textit{HTTP}, bien que cette technique ne soit pas utilisée et nécessite de gérer les exigences complexes de \textit{WebDAV}. Un des intérêts à permettre de pousser par \textit{HTTP} est que vous pouvez utiliser sur n'importe quel serveur \textit{WebDAV}, sans liaison avec \textit{Git}. Il est donc possible d'utiliser cette fonctionnalité si notre fournisseur d'hébergement web supporte \textit{WebDAV} pour la mise à jour de nos sites.
				\subparagraph{Avantages}
					L'avantage d'utiliser le protocole \textit{HTTP} est qu'il est très simple à mettre en \oe{}uvre. Donner un accès public en lecture à notre dépôt \textit{Git} ne nécessite que quelques commandes. Cela ne prend que quelques minutes. De plus, le protocole \textit{HTTP} n'est pas très demandeur en ressources système. Les besoins étant limités à servir des données statiques, un serveur \textit{Apache} standard peut servir des milliers de fichiers par seconde en moyenne et il est très difficile de surcharger même un ordinateur moyen.

					Un autre avantage indéniable de \textit{HTTP} est que c'est un protocole si commun que les pare-feux d'entreprise sont souvent paramétrés pour le laisser passer.
				\subparagraph{Inconvénients}
					L'inconvénient majeur de servir votre dépôt sur \textit{HTTP} est que c'est relativement inefficace pour le client. Cela prend généralement beaucoup plus longtemps de cloner ou tirer depuis le dépôt et il en résulte un plus grand trafic réseau et de plus gros volumes de transfert que pour les autres protocoles. Le protocole \textit{HTTP} est souvent appelé le protocole idiot parce qu'il n'a pas l'intelligence de sélectionner seulement les données nécessaires à transférer du fait du manque de traitement dynamique côté serveur.
			
			Parmi tous ces solutions on a choisi \textit{SSH} qui est relativement rapide, sécurisé et aussi simple à installer.
		\subsubsection{Développements distribués}
			A la différence des systèmes de gestion de version centralisés (\textit{CVCS}), la nature distribuée de \textit{Git} permet une bien plus grande flexibilité dans la manière dont les développeurs collaborent sur un projet. Dans les systèmes centralisés, tout développeur est un nœud travaillant de manière plus ou moins égale sur un concentrateur central. Dans \textit{Git} par contre, tout développeur est potentiellement un nœud et un concentrateur, c'est-à-dire que chaque développeur peut à la fois contribuer du code vers les autres dépôts et maintenir un dépôt public sur lequel d'autres vont baser leur travail et auquel ils vont contribuer. Cette capacité ouvre une perspective de modes de développement pour notre projet ou notre équipe dont certains archétypes tirant parti de cette flexibilité seront traités dans les sections qui suivent.
			\paragraph{Gestion centralisée}
				Dans les systèmes centralisés, il n'y a généralement qu'un seul modèle de collaboration, la gestion centralisée. Un concentrateur ou dépôt central accepte le code et tout le monde doit synchroniser son travail avec. Les développeurs sont des nœuds, des consommateurs du concentrateur, seul endroit où ils se synchronisent (FIGURE 3.1).

				\begin{figure}[htb]
					\centering\includegraphics[width=0.7\linewidth]{./img/schemagit.png}
					\caption{Gestion centralisée}
				\end{figure}

				Cela signifie que si deux développeurs clonent depuis le concentrateur et qu'ils introduisent tous les deux des modifications, le premier à pousser ses modifications le fera sans encombre. Le second développeur doit fusionner les modifications du premier dans son dépôt local avant de pousser ses modifications pour ne pas écraser les modifications du premier. Ce concept reste aussi vrai avec \textit{Git} qu'il l'est avec \textit{Subversion} (ou tout autre \textit{CVCS}) et le modèle fonctionne parfaitement dans \textit{Git}.

				\textit{Git} empêchera les utilisateurs d'écraser le travail des autres. Si un développeur clone le dépôt central, fait des modifications et essaie de les pousser alors qu'un autre développeur à poussé ses modifications dans le même temps, le serveur rejettera les modifications du premier. Il lui sera indiqué qu'il cherche à pousser des modifications sans mode avance rapide et qu'il ne pourra pas le faire tant qu'il n'aura pas récupéré et fusionné les nouvelles modifications depuis le serveur. Cette méthode est très intéressante pour de nombreuses personnes car c'est un paradigme avec lequel beaucoup sont familiers et à l’aise.
			\paragraph{Mode du gestionnaire d'intégration}
				Comme \textit{Git} permet une multiplicité de dépôt distants, il est possible d’envisager un mode de fonctionnement où chaque développeur a un accès en écriture à son propre dépôt public et en lecture à tous ceux des autres. Ce scénario inclut souvent un dépôt canonique qui représente le projet «officiel». Pour commencer à contribuer au projet, nous créons notre propre clone public du projet et poussez nos modifications dessus. Après, il suffit d'envoyer une demande au mainteneur de projet pour qu'il tire nos modifications dans le dépôt canonique. Il peut ajouter notre dépôt comme dépôt distant, tester nos modifications localement, les fusionner dans sa branche et les pousser vers le dépôt public. Le processus se passe comme ceci (FIGURE 3.2) :
				\begin{itemize}
					\item Le mainteneur du projet pousse vers son dépôt public;
					\item Un contributeur clone ce dépôt et introduit des modifications;
					\item Le contributeur pousse son travail sur son dépôt public;
					\item Le contributeur envoie au mainteneur un e-mail de demande pour tirer depuis son dépôt;
					\item Le mainteneur ajoute le dépôt du contributeur comme dépôt distant et fusionne localement;
					\item Le mainteneur pousse les modifications fusionnées sur le dépôt principal.
				\end{itemize}

				\begin{figure}[htb]
					\centering\includegraphics[width=0.9\linewidth]{./img/gestionInt.png}
					\caption{Le mode du gestionnaire d'intégration}
				\end{figure}

				C'est une gestion très commune sur des sites tels que \textit{GitHub} où il est aisé de dupliquer un projet et de pousser ses modifications pour les rendre publiques. Un avantage distinctif de cette approche est qu’il devient possible de continuer à travailler et que le mainteneur du dépôt principal peut tirer les modifications à tout moment. Les contributeurs n'ont pas à attendre le bon-vouloir du mainteneur pour incorporer leurs modifications. Chaque acteur peut travailler à son rythme.
			\paragraph{Mode dictateur et ses lieutenants}
				C'est une variante de la gestion multi-dépôt. En général, ce mode est utilisé sur des projets immenses comprenant des centaines de collaborateurs. Un exemple connu en est le noyau \textit{Linux}. Des gestionnaires d'intégration gèrent certaines parties du projet. Ce sont les lieutenants. Tous les lieutenants ont un unique gestionnaire d'intégration, le dictateur bénévole. Le dépôt du dictateur sert de dépôt de référence à partir duquel tous les collaborateurs doivent tirer. Le processus se déroule comme suit (FIGURE 3.3) :

				\begin{itemize}
					\item Les développeurs de base travaillent sur la branche thématique et rebasent leur travail sur master. La branche master est celle du dictateur;
					\item Les lieutenants fusionnent les branches thématiques des développeurs dans leur propre branche master;
					\item Le dictateur fusionne les branches master de ses lieutenants dans sa propre branche master;
					\item Le dictateur pousse sa branche master sur le dépôt de référence pour que les développeurs se rebasent dessus.
				\end{itemize}

				\begin{figure}[htb]
					\centering\includegraphics[width=0.9\linewidth]{./img/lieutenant.png}
					\caption{Le processus du dictateur bénévole}
				\end{figure}

				Ce schéma de processus n'est pas très utilisé mais s'avère utile dans des projets très gros ou pour lesquels un ordre hiérarchique existe, car il permet au chef de projet (le dictateur) de déléguer une grande partie du travail et de collecter de grands sous-ensembles de codes à différents points avant de les intégrer.

		Etant donné que le nombre de développers n'est pas énorme, on a choisi la gestion centralisée.
		\subsection{Gestion d'autorité}
            Pour réaliser l'installation initiale d'un serveur \textit{Git}, nous avons exporté un dépôt existant dans un nouveau dépôt nu -- un dépôt qui ne contient pas de copie de répertoire de travail.

            Apèe que nous avons une copie nue de notre dépôt, il ne restait plus qu'à la placer sur un serveur et à régler les protocoles. Nous avons mis en place un serveur auquel nous avons accès par \textit{SSH} et nous avons souhaité y stocker nos dépôts \textit{Git}. Nous avons mis en place notre dépôt en copiant le dépôt nu.

            A partir de ce moment-là, tous les autres utilisateurs disposant d'un accès \textit{SSH} au serveur et ayant un accès en lecture seule pouvait cloner notre dépôt.

            Si un utilisateur se connectait par \textit{SSH} au serveur et avait accès en écriture, il aurait automatiquement accès pour pousser.

            Dans le côté serveur, nous avons créé les comptes pour chacun des membres d'équipe. Pour le serveur, ce mode était similaire que tous les utilisateurs différents ont travaillé sur la même machine (FIGURE 3.4). Dans ce cas là, la gestion d'autorité était faite en changeant la mode de fichier.
			\begin{figure}[htb]
				\centering\includegraphics[width=0.5\linewidth]{./img/ssh.pdf}
				\caption{Installation de \textit{Git} sur un serveur}
			\end{figure}

	\subsection{Problème rencontré}
        Après quelques semaines de travail, nous avons découvert les inconvénients de cette solution :

        \begin{itemize}
            \item La création des comptes pour tout le monde était logique mais peut s'avérer lourd. Nous ne souhaiterions sûrement pas de'entrer un mot de passe temporaire pour chaque utilisateur;
            \item L'inconvénient critique était que nous avions une grande possibilité d'avoir les fichiers qui ont des propriétaires variés. Si un fichier temporaire généré par \textit{Git} a eu un propriétaire spécial, les autres utilisateurs ne pourraient pas réussir à pousser les données.
        \end{itemize}

	\subsection{Changement de la solution}
        La nouvelle méthode a consisté à créer un seul utilisateur \textit{git} sur la machine, demander à chaque développeur nécessitant un accès en écriture de m'envoyer une clef public \textit{SSH} et d'ajouter la dite clef au fichier \textit{authorized\_keys} de l'utilisateur \textit{git}. A partir de là, tout le monde serait capable d'accéder à la machine via l'utilisateur \textit{git}. Cela n'a affecté en rien les données de commit -- les informations de l'utilisateur \textit{SSH} par lequel on s'a connecté n'ont affecté pas les données de commit enregistrées.
        \subsubsection{Génération des clefs publiques \textit{SSH}}
            Cela dit, de nombreux serveurs \textit{Git} utilisent une authentification par clefs publiques \textit{SSH}. Pour fournir une clef publique, chaque utilisateur de notre système devait la générer s'il n'en a pas eu déjà.

            Après, chaque utilisateur ayant suivi ces indications a envoyé la clef publique à la personne en charge de l'administration du serveur \textit{Git}.
        \subsubsection{Mise en place du serveur}
            Parcourons les étapes de la mise en place d'un accès \textit{SSH} côté serveur. Premièrement, nous avons créé un utilisateur '\textit{git}' et un répertoire \textit{.ssh} pour cet utilisateur.

            Ensuite, nous avons ajouté la clef publique d'un développeur au fichier \textit{authorized\_keys} de l'utilisateur \textit{git}.

            A la fin, les autres utilisateurs pouvaient cloner le dépôt et y pousser leurs modifications aussi simplement.
	\subsection{Résultats obtenus}
        De cette manière, nous avons pu rapidement mettre en place un serveur \textit{Git} en lecture/écriture pour une poignée de développeurs. Elle était simple à configurer et rapide à réaliser. Nous n'avions plus de problème de propriétaire du fichier, car pour le serveur tous les fichiers étaient créés par l'utilisateur \textit{git} (FIGURE 3.5).

		\begin{figure}[htb]
			\centering\includegraphics[width=0.5\linewidth]{./img/sshgit.pdf}
			\caption{Connexion \textit{SSH} en utilisant le ficher \textit{authorized\_keys}}
		\end{figure}

        Il y avait encore quelques inconvénients de cette solution, qui n'étaient pas très graves en comparant avec le problème de conflit :

        \begin{itemize}
            \item L'utilisateur '\textit{git}' pouvait ouvrir un \textit{shell}. En précaution supplémentaire, nous pouvions simplement restreindre l'utilisateur '\textit{git}' à des actions \textit{Git} avec un \textit{shell} limité appelé \textit{git-shell} qui était fourni avec \textit{Git}. Si nous positionnions ce \textit{shell} comme \textit{shell} de login de l'utilisateur '\textit{git}', l'utilisateur \textit{git} ne pouvait pas avoir de \textit{shell} normal sur ce serveur.q
            \item Conserver les clefs publiques de tous les utilisateurs dans le fichier \textit{authorized\_keys} n'était satisfaisant qu'un temps. Avec des centaines d'utilisateurs, la gestion devenait compliquée. A chaque fois, il faillait se connecter au serveur et il n'y avait aucun contrôle d'accès -- toute personne avec une clef dans le fichier avait accès en lecture et écriture à tous les projets.
			\item L'autorité ne fonctionnait que pour une machine. Si le développeur voulait travailler sur une autre machine, il devait soit regénérer et envoyer un fichier du clef publique, soit porter le fichier de la clef privé depuis la machine où il avait travaillé.
        \end{itemize}

%    Étude du cahier des charges
%    Propositions et critiques de solutions
%    Description complète de la solution choisie
%    Mise en oeuvre
%    Résultats obtenus (critique)
\section{Gestion automatique de compte}
    \subsection{La problématique}
        Pour un utilisateur qui veut jouer sur la plate-forme \textit{Pokerlegend}, un compte est necessaire. Un compte a quatre états : en attente, validé, suspendu et supprimé. Quand l'utilisateur s'inscrit sur le site, il aura un compte en attente qui ne suffit pas pour jouer avec. Donc il faut valider le compte avec le code d'activation réçu après l'inscription. Si 15 jours après l'inscription l'utilisateur n'aurais touojurs pas validé son compte, le compte serait suspendu. Encore 30 jours d'après si l'utilisateur ne valide pas, son compte sera supprimé (FIGURE 3.6). 

		\begin{figure}[htb]
			\centering\includegraphics[width=0.7\linewidth]{./img/compte.pdf}
			\caption{Les états d'un compte d'utilisateur}
		\end{figure}

        Toutes ces gestions de compte deveient être faites automatiquement par le serveur. Ce que le client a demandé est une solution fiable et aussi facile à personnalisé.
    \subsection{Propositions de solutions}
        Il y a deux parties pour réaliser la gestion automatique de compte, une partie pour exécuter le script répétivement et une autre pour modifier le base de données (FIGURE 3.7).

		\begin{figure}[htb]
			\centering\includegraphics[width=0.3\linewidth]{./img/gestionAuto.pdf}
			\caption{Les deux parties de la gestion automatique de compte}
		\end{figure}

        \subsubsection{Exécution automatique}
            Il y a plusieurs façons d'exécuter un script répétivement : \textit{cron}, \textit{php}, \textit{bash} etc.
            \paragraph{\textit{cron}} \textit{cron} est le nom d'un programme qui permet aux utilisateurs des systèmes \textit{Unix} d'exécuter automatiquement des scripts, des commandes ou des logiciels à une date et une heure spécifiées à l'avance, ou selon un cycle défini à l'avance.

            \textit{cron} est un service (daemon), ce qui -- dans le jargon informatique -- désigne un programme qu'on ne lance qu'une seule fois après le démarrage de l'ordinateur et qui reste en tâche de fond en attendant qu'on ait besoin de lui. Le service \textit{cron} (\textit{crond}) attend ainsi jusqu'au moment spécifié dans le fichier de configuration (que l'on appelle le \textit{crontab}) puis effectue l'action correspondante et se rendort jusqu'à l'événement suivant.

            Le service \textit{cron} est lancé par le compte \textit{root} afin de pouvoir s'adapter à l'identité de chacun des utilisateurs. Sur certains \textit{Unix}, si on le tue (par la commande \textit{kill}), il est automatiquement relancé par le système.
                \subparagraph{Avantages}
                    \begin{itemize}
                        \item \textit{cron} est souvent déjà integré dans le système \textit{Linux};
                        \item Il est fiable et aussi rapide.
                    \end{itemize}

                \subparagraph{Inconvénients}
                    \begin{itemize}
                        \item Pour activer et desactiver \textit{cron} il faut l'autorité de \textit{root};
                        \item Il ne supporte que les dates absolues.
                    \end{itemize}

            \paragraph{\textit{php}, \textit{bash} et les autres languages de script}
                Une autre solution était de faire un programme (script) qui a un boucle infini. Dans le boucle on verifie si on a besoin de modifier le base de données.
                \subparagraph{Avantage}
                    Il est possible d'integrer la manipulation de la base de données dans le script.
                \subparagraph{Inconvénients}
                    \begin{itemize}
                        \item L'exécution de script est lourde pour le serveur;
                        \item Un boucle infini augmente le risque de bloquer le script.
                    \end{itemize}

            Le facteur plus important est la fiabilité, on a donc choisi \textit{cron} pour assurer que le script tourne tout le temps.
        \subsubsection{Manipulation de la base de données}
            Pour accéder la base de donnés on peut utiliser \textit{php}, \textit{SQL} ou un navigateur.
            \paragraph{\textit{php}}
                Le site était réalisé à l'aide du framework \textit{Web:Extend}. Avec les fonctions de \textit{Web:Extend} nous pouvions accéder la base de données facilement. Pour utiliser les fonctions du framework, ainsi que les configurations, il faut une initialisation qui comporte trop de fonctionnalités. Elle est suffisante même pour afficher tout le site.
                \subparagraph{Avantage}
                    A l'aide de tous ce qui sont faits concernant la base de données sur le site, nous pouvions manipuler directement les données.
                \subparagraph{Inconvénients}
                    \begin{itemize}
                        \item Les fonctionnalités du framework n'est jamais conçues pour l'utilisation en ligne de commande. Pour l'utiliser nous devions faire quelques modifications;
                        \item L'initialisation du programme qui contient tous les fonctionnalités du site, utilisé seulement pour exécuter une commande sur la base de données était un peu coûteuse;
                        \item Le script \textit{php} n'est pas très efficace pour la base de données, surtout après les emballages des objets et du framework.
                    \end{itemize}

            \paragraph{\textit{SQL}}
                La deuxième solution était d'écrire un script \textit{progreSQL} pur.
                \subparagraph{Avantage}
                    Avec cette manière nous avons pu minimiser les ressources utilisées, donc ça sera très rapide.
                \subparagraph{Inconvénient}
                    Il faillait refaire la configuration pour la base de données, qui pouvait causer le problème de l'incohérence que celui du framework.

            \paragraph{Navigateur}
                La troisème solution était de faire une page web qui pouvait envoyer une requête \textit{SQL} fixé à la base de données. Grâce à \textit{Web:Extend} cette page pouvait être générée très rapidement. Quand un utilisateur a visité sur cette page, la manipulation des données serait faite. Nous pouvions utiliser un navigateur en mode texte (par exemple, \textit{lynx}) pour visiter la page.
                \subparagraph{Avantage}
                    \begin{itemize}
                        \item La solution était simple et rapide à réalisée;
                        \item Le fonctionnement était complètement pareil qu'une page normale, tous les configurations du framework seriont réutilisable.
                    \end{itemize}
                \subparagraph{Inconvénient}
                    \begin{itemize}
                        \item L'initialisation du programme qui contient tous les fonctionnalités du site, utilisé seulement pour exécuter une commande sur la base de données était un peu coûteuse;
                        \item Théoriquement l'utilisateur avait l'occasion de accéder à cette page et d'appeler la fonction intégrée dans la page. Ça causerait un grand problème de sécurité.
                    \end{itemize}

            Le script serait exécute une fois par jour, soit tous les minuits car à ce moment-là il y aurait peu de joueurs en ligne. Donc l'efficacité n'était pas un problème important. La réutilisation de la configuration était plus important comme nous ne voulions pas modifier deux fois la configuration s'il y avait des changements à faire. Donc nous avons choisi la solution en \textit{php}.
    \subsection{Mise en \oe{}uvre}
        Une page web était créée comme l'interface pour l'administrateur du site. Avec cette page il pouvait :

        \begin{description}
            \item [Activer et desctiver le service \textit{cron}] C'était une opération qui a besoin de l'autorité de \textit{root}, donc il faillait ajouter l'utilisateur de \textit{php} dans le fichier \textit{sudoer}. Ce fichier a permis de donner l'autorité à certain utilisateur pour lancer certain commande avec ou sans mot de passe;
            \item [Modifier le ficher \textit{crontab}] Ce fichier était l'entrée de \textit{cron}. Il a défini le temps d'exécution et la commande exécutée.
        \end{description}

        Quand \textit{cron} était activé il lisait le fichier \textit{crontab} toutes les minutes. Une fois le temps d'exécution était arrivé, il lancerait la commande suivante. La commande contenait le nom du programme (pour exécuter le script \textit{php}) et les arguments (pour personnaliser la condition de changement d'état de comptes) (FIGURE 3.8).

        \begin{figure}[htb]
			\centering\includegraphics[width=0.7\linewidth]{./img/crontab.pdf}
			\caption{La réalisation de la gestion automatique de compte}
		\end{figure}

    \subsection{Résultats obtenus}
        Comme nous l'avons dit au dessus, théoriquement ce n'était pas une solution optimisée. L'autre inconvénient était que la façon pour définir le temps d'exécution est plutôt lisible pour un programme mais pas pour un humain. Comme l'administrateur du site n'était pas un informaticien nous avions laissé seulement quelques choix usuels dans la page. C'était plus facile à utiliser mais c'a réduit la fonctionnalité de \textit{cron} en même temps.
\section{Développement de table de jeu}
    \subsection{La problématique}
        \subsubsection{Exigence du client}
            La page de table de jeu état la partie plus importante du site. Tous les sorts de jeux -- jeux simples, tournois -- seraient finalement réalisés sur cette page. Ce qui était demandé par le client était une page qui marchait avec la règle cohérente que celui en réel. Les bruits et animations étaient aussi demandés pour améliorer l'experience d'utilisateurs.
        \subsubsection{Technologies utilisées}
            \begin{itemize}
                \item \textit{Web:Extend}/\textit{php}/\textit{POO},
                \item \textit{MVC},
                \item \textit{Javascript}/\textit{AJAX}/\textit{Taconite},
                \item \textit{progreSQL}.
            \end{itemize}

    \subsection{Mise en \oe{}uvre}
        \subsubsection{Rappel de la règle du \textit{Texas hold'em}}
            \paragraph{Présentation}
            Le \textit{Texas hold'em} (littéralement «Texas retiens-les») ou communément \textit{hold'em} (\textit{HE}) est une variante du poker. Elle constitue la variante la plus jouée et la plus connue, notamment dans sa forme \textit{no-limit} (\textit{NL}), c'est-à-dire sans restriction maximale de mise ou de relance, utilisée au cours de l'épreuve principale des \textit{World Series of Poker}, le plus gros tournoi de poker du monde en termes de gains et de popularité.

            Le \textit{hold'em} se joue à partir de deux joueurs en face à face (\textit{heads-up}) et jusqu'à dix joueurs en table complète (\textit{full ring}). Le but du jeu est de remporter les jetons des autres joueurs en ayant la meilleure main ou en leur faisant jeter leurs cartes (\textit{fold}).

            \paragraph{Déroulement d'un coup}
                \begin{itemize}
                    \item Avant la distribution des cartes, les deux joueurs à la gauche du donneur doivent s'acquitter des \textit{blinds}. Le joueur placé directement à gauche du donneur paie la petite blind et son voisin de gauche la grande;

                    \item Le joueur qui a le jeton du donneur (dealer en anglais), appelé aussi le bouton, bat les cartes et demande à la personne à sa droite de couper puis distribue les cartes, sauf en présence d'un croupier, qui se charge alors de l'opération; mais celui qui a le bouton est tout de même appelé «donneur». La distribution se fait en deux tours horaires : chaque fois, une carte est donnée face cachée à chaque joueur, en partant du small blind. A la fin de la donne, les joueurs ont donc deux cartes, dont eux seuls ont connaissance. Le joueur a la responsabilité de protéger ses cartes, notamment lorsqu'il prend connaissance de son jeu. Ces deux cartes, les seules que le joueur recevra individuellement, ne seront éventuellement dévoilées qu'au moment de l'abattage (\textit{showdown} en anglais);

                    \item Quand tous les joueurs ont pris connaissance de leur jeu, commence un tour de mise pré-flop qui débute par le joueur à la gauche de la grosse blind, appelé \textit{UTG} (\textit{Underthegun}) et continue dans le sens horaire;

                    \item Après le premier tour de mise, le donneur «brûle» une carte face cachée puis étale le flop : trois cartes sont retournées faces visibles ; ces cartes sont communes à tous les joueurs. Combinées avec les deux cartes «privées» que chaque joueur tient cachées, elles serviront à la constitution des mains. L'ensemble des cartes communes posées sur la table constitue la tableau («board en anglais»);

                    \item Nouveau tour de mises. Le joueur à la gauche du donneur commence à miser. Il en sera de même pour tous les tours de mises suivants;

                    \item Le donneur brûle une carte et en retourne une nouvelle au centre : le tournant («the turn» en anglais) ou encore fourth street qui servira aussi dans les combinaisons de chaque joueur;

                    \item Nouveau tour de mises;

                    \item Le donneur brûle une dernière carte et en retourne une cinquième et dernière au centre : the river («la rivière») ou encore fifth street;

                    \item Dernier tour de mises;

                    \item L'abattage (ou showdown en anglais) : les mains des joueurs encore en jeu s'affrontent;

                    \item Chaque joueur présente une main de cinq cartes choisies parmi ses deux cartes privées et les cinq cartes de la tableau. Il faut souligner que le joueur peut inclure dans sa combinaison de cinq cartes ses deux cartes privées, ou une seule, ou même aucune s'il le désire (par exemple, lorsque la combinaison des cinq cartes de la tableau est la meilleure qu'il puisse obtenir). Le joueur ayant la meilleure main emporte le pot. En cas d'égalité, celui-ci est partagé;

                    \item Le donneur passe alors le bouton au joueur à sa gauche, celui qui était donc de petite blind, un nouveau coup peut alors commencer (FIGURE 3.9).
                \end{itemize}

                \begin{figure}[htb]
			        \centering\includegraphics[width=0.8\linewidth]{./img/htable.png}
			        \caption{Schéma d'une table de jeu au \textit{Texas hold'em}}
		        \end{figure}   

        \subsubsection{Modèle de \textit{Web:Extend}}
            Le framework \textit{Web:Extend} était utilisé pour générer tout le site. L'idée principale de \textit{Web:Extend} était de séparer la partie de programmation et la partie d'affichage d'un site, soit partie \textit{php} et la partie \textit{HTML}.

            La partie \textit{php} était programmée sous le concept de \textit{POO}. Cette partie avait deux composants, un était «model» l'autre était «frame». «Model» était chargé d'envoyer des requêtes à la base de données. «Frame» calculait et affectait les variables necessaires pour l'affichage de la page (FIGURE 3.10).

            \begin{figure}[htb]
			    \centering\includegraphics[width=0.8\linewidth]{./img/webExtend.pdf}
			    \caption{Le modèle de \textit{Web:Extend}}
		    \end{figure}

        \subsubsection{Structure de la base de données}
            Il a existé un schéma de la base de données avant que je suit arrivé. Le but était de minimiser la modification en respectant les règles suivantes :

            \begin{itemize}
                \item Une table était un conteneur de jeux qui définit les caractéristiques des jeux effectués sur cette table,
                \item Un utilisateur pouvait jouer dans plusieurs tables en même temps,
                \item Tous les jeux devaient être reproductibles à l'aide des données.
            \end{itemize}

            Donc nous avons proposé un schéma de la base de données comme ceci (FIGURE 3.11):

            \begin{figure}[htb]
			    \centering\includegraphics[width=0.6\linewidth]{./img/sql.pdf}
			    \caption{Schéma des tableaux de la base de données}
		    \end{figure}

            La table \textit{tables} était utilisée pour enregistrer les données qui caractériseient les jeux et les données temporaires de jeux. La table \textit{games} était utilisée pour enregistrer les données utiles pour reproduire les déroulements des jeux. La table \textit{players} était pour stocker le rôle d'un utilisateur dans un jeu. La table \textit{events} était pour noter l'histoire des jeux. Un événement pouvait être fait par un joueur (par exemple un mise) ou appartenir à un jeu (par exemple le commencement du jeu). Pour reconstruire un jeu il faillait rechercher tous les événements qui appartenaient à ce jeu ou qui étaient faits par un joueur du jeu.

            Pour que tous séraient reproductibles nous ne supprimions rien de la base de données. Quand nous voulions «supprimer» une chose, nous le marquions «supprimé» mais les données étaient encore existantes.

            Parcourons les étapes des opérations de la base de données pendant les jeux :

            \begin{itemize}
                \item Une table est créée par l'administrateur à l'aide une interface de la page web;
                \item Une table a toujours un jeu courant et plusieurs jeux passés. Dès que la table est créée, un jeu est créé automatiquement, mais sa date de démarrage est vide;
                \item Quand un joueur rejoint une table, il crée un joueur (avec une réduction d'argent du compte de l'utilisateur, qui égale l'argent du joueur) et le joueur rejoint le jeu sur la table. Le jeu est soit en attente soit en cours;
                \item L'utilisateur peut rejoindre un autre table en même temps, dans ce cas là il va créer un autre joueur. Les joueurs d'un même utilisateur sur les tables différentes sont indépendants;
                \item Quand il y a plus que 2 joueurs sur la table, le jeu serait commencé;
                \item Les joueurs jouent et toutes les actions sont enregistrées comme les événements;
                \item La table note l'étape en cours qui est utile pour le déroulement du jeu mais non utile pour la reproduction;
                \item Quand le jeu est fini on distribue l'argent du pot du jeu aux joueurs;
                \item Si un joueur quite, il sera supprimé et son argent sera retourné au compte de son utilisateur;
                \item Pour les joueurs non quités on note ses utilisateurs. Puis le jeu courant est marqué «fini». Un nouvel jeu est crée sur la même table et les nouveaux joueurs sont créés pour les utilisateurs notés avant;
                \item Le nouvel jeu commence...
            \end{itemize}

        \subsubsection{\textit{MVC}}
            \paragraph{Utilisation de \textit{MVC}}
                Le Modèle-Vue-Contrôleur (en abrégé \textit{MVC}, de l'anglais \textit{Model-View-Controller}) est une architecture et une méthode de conception qui organise l'interface homme-machine (\textit{IHM}) d'une application logicielle. Ce paradigme divise l'\textit{IHM} en un modèle (modèle de données), une vue (présentation, interface utilisateur) et un contrôleur (logique de contrôle, gestion des événements, synchtronisation), chacun ayant un rôle précis dans l'interface.

                Le schéma de la figure suivante (FIGURE 3.12) résume les différentes interactions entre le modèle, la vue et le contrôleur. Les lignes pleines indiquent une association directe tandis que les pointillés sont une association indirecte.

                \begin{figure}[htb]
			        \centering\includegraphics[width=0.7\linewidth]{./img/mmvc.png}
			        \caption{Modèle \textit{MVC}}
		        \end{figure}

                Pour nous le modèle était sur le serveur, soit les programmes en \textit{php} et la base de données. La vue (les éléments visuels) et le contrôleur (les boutons) étaient à côté client, soit la page web (FIGURE 3.13).

                \begin{figure}[htb]
			        \centering\includegraphics[width=0.8\linewidth]{./img/mvc.pdf}
			        \caption{Schéma \textit{MVC} du projet}
		        \end{figure}

            Théoriquement nous devions être capable de faire un coup de jeu totalement sur le serveur avec les fonctions définies pour rejoindre, miser petit blind ou grosse blind, payer, relancer etc. En réel les appels des fonctions étaient faits par joueur, soit le côté client.

            \paragraph{Contrôleur et \textit{AJAX}}
                Le contrôleur contenait plusieurs boutons. Quand le client a cliqué sur un bouton une requête \textit{AJAX} serait envoyée. L'intérêt de l'utilitsation de l'\textit{AJAX} étaut qu'il a permis les opérations sur le modèle sans rafraichissment de la page.

                En informatique, et plus particulièrement en architecture informatique, \textit{AJAX} (acronyme de \textit{Asynchronous Javascript and XML}) est une manière de construire des applications web et des sites web dynamiques basés sur diverses technologies web ajoutées aux navigateurs.

                Dans une application web, la méthode classique de dialogue entre un navigateur et un serveur est la suivante : lors de chaque manipulation faite par l'utilisateur, le navigateur envoie une requête contenant une référence à une page web, puis le serveur web effectue des calculs, et envoie le résultat sous forme d'une page web à destination du navigateur. Celui-ci affichera alors la page qu'il vient de recevoir. Chaque manipulation entraîne la transmission et l'affichage d'une nouvelle page et l'utilisateur doit attendre l'arrivée de la réponse pour effectuer d'autres manipulations.

                En utilisant \textit{AJAX}, le dialogue entre le navigateur et le serveur se déroule la plupart du temps de la manière suivante : un programme écrit en langage de programmation \textit{Javascript}, incorporé dans une page web, est exécuté par le navigateur. Celui-ci envoie des demandes de calcul au serveur web, puis modifie le contenu de la page actuellement affichée par le navigateur web en fonction du résultat reçu du serveur, évitant ainsi la transmission et l'affichage d'une nouvelle page.

                La méthode classique de dialogue utilise des mécanismes propres au \textit{World Wide Web}, qui sont incorporés dans tous les navigateurs ainsi que les robots d'indexation, et ne nécessite pas de programmation. A contrario, le fonctionnement d'\textit{AJAX} nécessite de programmer les dialogues entre le navigateur et le serveur web. Il nécessite également de programmer les modifications à effectuer dans la page Web, sans quoi les dialogues se font à l'insu de l'utilisateur.

                En \textit{AJAX}, comme le nom l'indique, les demandes sont effectuées de manière asynchrone : le navigateur web continue d'exécuter le programme \textit{Javascript} qui envoie la demande dès que celle-ci est partie, il n'attend pas la réponse envoyée par le serveur web et l'utilisateur peut continuer à effectuer des manipulations (FIGURE 3.14).

                \begin{figure}[htb]
			        \centering\includegraphics[width=\linewidth]{./img/ajax.png}
			        \caption{Dialogue entre serveur et navigateur}
		        \end{figure}

                Le contrôleur était réalisé dans le navigateur, soit à côté client. Donc théoriquement les opérations faites par le contrôleur étaient seulement vérifiées et validées à côté clien. Pour éviter qu'un joueur trichait, le contrôleur ne pouvait pas vraiment faire une opération sur la base de données. Ce qu'il a fait était plutôt d'envoyer une demande d'opération. La demande était toujours finalement vérifiée à côté serveur.

                Par exemple, dans une page il y a deux boutons, bouton \textit{A} et bouton \textit{B}. Suivant la règle du jeu le bouton \textit{B} est caché temporairement. Quand le joueur clique sur le bouton \textit{A} une requête sera envoyée et la demande est vérifiée à côté serveur. Si elle est validée, l'opération sur la base de données est faite (FIGURE 3.15).

                \begin{figure}[htb]
			        \centering\includegraphics[width=0.5\linewidth]{./img/mvca.pdf}
			        \caption{Opération légale}
		        \end{figure}

                Si le bouton \textit{B} n'est pas caché correctement (l'utilisateur à modifie la page \textit{HTML} manuellement, il utilise un navigateur personnalisé ou il y a un problème d'affichage), le joueur peut envoyer la demende d'une opération illégale en cliquant sur bouton \textit{B}. Le serveur ne va rien faire s'il trouve que ce n'est pas une opération légale (FIGURE 3.16).
                \begin{figure}[htb]
			        \centering\includegraphics[width=0.5\linewidth]{./img/mvcr.pdf}
			        \caption{Opération illégale}
		        \end{figure}
            \paragraph{Vue et \textit{Taconite}}
                Le renouvellement de la vue était fait à l'aide de la table \textit{last\_updates} dans la base de données. Cette table enregistrait la date de dernière demande de renouvellement de l'utilisateur sur une certaine table. Quand l'utilisateur a envoyé une requête pour renouveler la page, la réponse était construite par rapport à les événements qui étaient crées plus tard que la date de la dernière mise à jour de l'utilisateur (FIGURE 3.17).

                \begin{figure}[htb]
			        \centering\includegraphics[width=\linewidth]{./img/lastUpdate.pdf}
			        \caption{rafraîchissement de la page}
		        \end{figure}

                Nous avons utilisé \textit{Taconite} pour traiter les réponses de renouvellement. \textit{Taconite} est un plugin de \textit{Javascript} qui permet de traiter automatiquement les réponses de serveur via \textit{AJAX}. Grâce à cette technique nous avons pu modifier les \textit{DOM}s, créer un \textit{DOM}, supprimer un \textit{DOM} ou lancer une commande en \textit{Javascript}.

                Son interêt était que la façon de traitement de réponse était défini avec un format spécial d'\textit{XML} (FIGURE 3.18), nous n'avions pas du tout besoin de programmer dans la côté client.
                \begin{figure}[htb]
			        \centering\includegraphics[width=0.9\linewidth]{./img/taconite.pdf}
			        \caption{Structure de message \textit{XML} de \textit{Taconite}}
		        \end{figure}
        \subsubsection{Compteur}
            Pour un jeu du poker nous avons toujours besoin d'un compteur d'heure. Par exemple, un joueur a 60 secondes pour faire une opération quand son tour arrive, un nouvel jeu commence dix secondes après le fin de vieux jeu etc.

            C'était sûr que le compteur devait être lancé sur le serveur. L'indicateur qui tournait à côté client devait être synchronisé avec le compteur du serveur. 

            La première solution était de créer un compteur quand il y avait une opération périodique. Le probmème critique était que la création de compteur était traitée comme une requête, et un utilisateur ne pouvait faire qu'une requête en même temps. Par exemple, quand un utilisateur commence à jouer à son tour, une requête est envoyer pour lancer un compteur sur le serveur. A ce moment là, tous les autres requêtes de l'utilisateur seront suspendues, c'est-à-dire l'utilisateur ne peut ni rafraîchir la page ni faire une opération (FIGURE 3.19).

            \begin{figure}[htb]
		        \centering\includegraphics[width=0.8\linewidth]{./img/phpConcu.pdf}
		        \caption{Les requêtes sont suspendus quand le compteur tourne}
	        \end{figure}

            La solution finale était de créer une table \textit{timer\_events} qui était une liste de tâche à faire. Quand un utilisateur commence à jouer il ajout une tâche pour faire coucher l'utilisateur 60 secondes après. Si l'utilisateur a fait la décision pendant 60 secondes, la tâche sera supprimée, si non la tâche sera effectuée donc l'utilisateur sera suspendu.

            Théoriquement ce qui était enregistré dans cette table était des redondances car tout son contenu était raisonable et calculable par rapport aux données des autres tables. L'interêt de cette solution était que le programme de compteur n'avait pas besoin de parcourir toute la base de données, donc la rapidité était assurée. Vue qu'il faillait vérifier s'il y avait des tâches à faire toutes les seconde, la rapidité de la solution était très importante.

        \subsubsection{Ajout de son}
            L'ajout de bruits pendant le jeu était regardé comme une amélioratoin d'expérience d'utilisateur. Mais nous avons rencontré beaucoup de problèmes causé par les navigateurs variés.

            L'avantage d'application dans la page web est qu'il est multiplate-forme, théoriquement elle marche pour certaines téléphones portables aussi. L'inconvénient est aussi grâve -- ce que nous avons a dévéloppé est seulement une description de notre programme, ça sera le navigateur qui va décider comment l'interpreter, la façon d'affichage etc.

            Malheusement le \textit{W3C} (World Wide Web Consortium) n'a pas encore défini un norme d'insertion de son dans la page web. Beaucoup de sites utilisent une façon qui ne marche que sous \textit{IE}. Aujourd'hui le plugin \textit{Flash} est aussi souvent utilisé pour intégrer les bruits, mais ça nécéssite le téléchargement du plugin externe.

            Notre choix était d'utiliser \textit{HTML5} pour ajouter les bruits. \textit{HTML5} est un nouvel norme de \textit{HTML} qui supporte son et vidéo par défaut. Bienque officiellement il n'est pas encore fini mais il n'y a pas mal de navigateurs qui supportent \textit{HTML5} partiellement.

            Les formats des fichiers de sons supportés par les navigateurs sont différents (FIGURE 3.20). \textit{HTML5} permet d'utiliser plusieurs fichers en formats différents pour un son, le navigateur va essayer de jouer le premier fichier jouable.

            \begin{figure}[htb]
		        \centering\includegraphics[width=0.8\linewidth]{./img/audio.png}
		        \caption{Les formats de son supporté par navigateurs (\textit{IE} commence à supporter \textit{HTML5} à partir de la version 9)}
	        \end{figure}
        \subsubsection{Animation}
            Pour faire les animations nous avons utilisé la fonction \textit{animate} du \textit{Javascript}. Ells pouvait faire tout ce que nous avions besoin : mouvement d'objet, zoom avant et arrière etc.

            Le manière dont elle fonctionne est un peu différente : les instructions sont parallèles. Quand on lance le programme, toutes les instructions sont enregistrées dans une séquance, l'ordre d'éxécution dépend la priorité des fonctions, les fonctions qui ont la même priorité seront éxécutées en même temps.

            Ici vient le problème. Supposons qu'objet \textit{A} va à position \textit{P3} depuis position \textit{P1} en passant position \textit{P2}. Deux animations seront éxécutées : objet \textit{A} va à position \textit{P2} depuis position \textit{P1} et objet \textit{A} va à position \textit{P3} depuis position \textit{P2} (FIGURE 3.21)

            \begin{figure}[htb]
		        \centering\includegraphics[width=0.9\linewidth]{./img/animations.pdf}
		        \caption{Animation séquencielle}
	        \end{figure}

            En réel \textit{Javascript} éxécute toutes les animations en même temps donc on voit que deux objet \textit{A} apparaient et déplacent en même temps (FIGURE 3.22).

            \begin{figure}[htb]
		        \centering\includegraphics[width=0.6\linewidth]{./img/animationp.pdf}
		        \caption{Animation parallèle}
	        \end{figure}

            La fonction \textit{animate} a un paramètre pour définir la tâche suivante de l'animation pour résoudre les problèmes comme ça, donc on peut lier toutes les animations par l'ordre. Mais ça ne marche pas si l'animation suivante n'est pas définie.

            Notre solution était de séparer les animations. Quand le navigateur a demandé le rafraîchissement et un ensemble d'animations était retourné il faillait assurer que toutes les animations dans l'ensemble peouvait être effectuées simutanément sans problème d'affichage. Si non l'ensemble devait être séparé en deux parties.

            Le serveur retournait les animations par rapport aux événements. Si le serveur a retourné une animation qui peut être dérangée par une autre, ça devait être la dernière animation de l'ensemble retourné. Une date fausse de dernière mise à jour qui égale à la date d'événement qui cause la dernière animation serait inserée dans la table \textit{last\_updates}. La prochaine fois la requête est arrivée le serveur lirait les événements à partir de l'événement où on s'arrete (FIGURE 3.23).

            \begin{figure}[htb]
		        \centering\includegraphics[width=\linewidth]{./img/lastUpdateB.pdf}
		        \caption{Animation parallèle}
	        \end{figure}

        \subsubsection{Les améliorations d'affichage}
            \paragraph{Disposition dynamique des élements}
                Au début, la disposition des éléments était définie dans le ficher \textit{CSS} avec le positionnement absolu en pixel (FIGURE 3.24). Le client a demandé une disposition dynamique qui adaptait la taille de la fenêtre (FIGURE 3.25).

                \begin{figure}[htb]
		            \centering\includegraphics[width=0.4\linewidth]{./img/dispos.pdf}
		            \caption{Disposition statique}
	            \end{figure}

                \begin{figure}[htb]
		            \centering\includegraphics[width=0.4\linewidth]{./img/dispod.pdf}
		            \caption{Disposition dynamique}
	            \end{figure}

                Nous avons essayé deux façons. La première était d'utiliser pourcentage au lieu de pixel. L'autre façon était de lancer une fonction en \textit{Javascript} pour recalculer la dispositon et repositionner les éléments quand un changement de taille de la fenêtre était détecté.

                Toutes ces deux solutions étaient lentes et unstables quand il y avait des animations. Donc nous avons laissé la disposition statique.
            \paragraph{Amélioration d'\textit{Accordion}}
                L'\textit{Accordion} est un composant de \textit{Javascript UI}. Il permet de générer un menu pliable. Nous l'avons utilisé pour afficher trois rubriques dans la table du jeu : règle du jeu, événements et méssages.

                L'incovénient était qu'il ne supporte qu'un menu déplié en même temps (FIGURE 3.26). Vue que l'exigence de regarder les événements et les messages était très générale pour l'utilisateur, nous avons cherché une manière pour réalisers l'affichage de plusieur rubriques simutanément.

                \begin{figure}[htb]
		            \centering\includegraphics[width=0.5\linewidth]{./img/accordion.pdf}
		            \caption{Les états différents d'\textit{Accordion} avec trois rubriques}
	            \end{figure}

                Bienque l'\textit{Accordion} était partiellement configurable, pour nous ce n'était pas suffisant. Nous avons refait un menu pliable à l'aide de la fonction \textit{animate}. Puis toutes les rubriques étaient plus indépendantes. Il y avait sept états de le nouvel menu (l'état où toutes les rubriques étaient fermées était interdit) (FIGURE 3.27).

                \begin{figure}[htb]
		            \centering\includegraphics[width=0.7\linewidth]{./img/accordionN.pdf}
		            \caption{Sept états possible du nouvel menu pliable}
	            \end{figure}
    \subsection{Résultats obtenus}
        Le jeu a été jouable à la fin. Mais nous avions encore quelques problèmes qui attendent une amélioration dans la futur.
        \subsubsection{Compteur}
            Comme dit au précédent le compteur était un programme qui tourne tous les jours et observe la base de données. Il était réalisé en \textit{php} avec un boucle infini. Il est prouvé que le \textit{php} n'est pas assez fiable pendant centaine heures. Nous avions toujours le risque que le programme crashait.

            Une solution était de refaire le programme avec une technologie plus fiable par exemple en \textit{C++}. L'autre solution moins couteuse était de faire un autre script en \textit{bash} pour observer le compteur \textit{php}. Si le compteur crashait, script \textit{bash} relancerait le compteur. Comme ça combinerait la fiabilité de \textit{bash} et la puissance de \textit{php}.

        \subsubsection{Requêtes concurrents}
            Une page de jeu envoyait une requête par seconde. Ce que le client a demandé est que l'utilisateur pouvait jouer sur dix tables. Pour assurer une meilleur d'expérience d'utilisateur, toutes les requêtes devait être répondues, c'est-à-dire le serveur avait 0,1 seconde pour répondre une requête. C'était impossible pour nous. Par rapport aux tests, quand nous avons eu trois tables nous auriont les erreurs d'affichage car certaines instructions d'animation étaient perdues.
\section{Développement du tournoi}
    \subsection{La problématique}
        \subsubsection{La règle du tournoi}
            Le tournois est en fait une organisation de plusieurs jeux avec élimination de joueur.

            Les étapes du déroulement d'un tournoi :
            \begin{itemize}
                \item Un tournoi est créé. Avant son commencement les utilisateurs peuvent s'inscrire au tournois. L'inscription nécessite un certain coût;
                \item Le tournoi commence quand il y a assez de joueurs inscrits et quand atteint le temps pour commencer;
                \item Tous les joueurs commencent à jouer avec le même montant de jetons;
                \item Les joueurs sont dans les tables différentes. Quand un jeu est fini on va déplacer certains joueurs aux autres tables pour équilibrer les nombres de joueurs de toutes les tables;
                \item Le tournoi a 30 niveaux. L'élévation de niveaux est accompagnée d'élévation de blinds;
                \item Toute les tables du tournoi sont toujours sur le même niveau;
                \item Quand on atteint la fin de la durée d'un niveau, il faut encore attendre les jeux en cours. Quand ils sont tous finis le niveau suivant commence;
                \item Entre chaque cinq niveaux, il y a une pause;
                \item Si un joueur n'a plus de jetons, il est éliminé. Pour éviter ça il peut racheter les jetons pendant les premiers cinq niveaux ou pendant la pause entre niveau 5 et niveau 6;
                \item Quand on arrive à la fin de niveau 30, le tournoi sera fini. Le nombre de jetons du joueur est seulement pour calculer sa position de classement.
            \end{itemize}
        \subsubsection{Exigences de client}
            \begin{itemize}
                \item Le tournoi devait être configurable en création,
                \item Un tournoi créé ne devait être visible pour les utilisateurs qu'après la validation de l'administrateur,
                \item Il y avait deux types de tournoi à part du tournois normal, \textit{Freezeout} et \textit{Sit \& Go}. Le tournoi de type \textit{Freezeout} éliminerait le joueur immédiatement s'il n'avait plus de jetons. Le tournoi \textit{Sit \& Go} n'avait pas une date de démarrage définie, il commencerait dès que le nombres de joueurs inscrits est arrives son nombre de joueurs minimal,
            \end{itemize}
    \subsection{Mise en \oe{}uvre}
        \subsubsection{Création de tables}
            Un tournoi est constitué par les tables et les jeux qui tournent sur ces tables. Quand un tournoi est créé, les tables qui l'appartien sont créées en même temps. Les différences entre une table normale et une table de tournoi est que ce dernier est liée avec un tournoi avec un attribut \textit{tournament\_id} et sa définition des blinds sera ignoré pendant les jeux car le tournoi a sa propre définition des blinds qui se varie par rapport au niveau en cour (FIGURE 3.28).

            \begin{figure}[htb]
	            \centering\includegraphics[width=0.6\linewidth]{./img/uml.pdf}
	            \caption{Schéma de la base de données du tournoi}
            \end{figure}

            Le nombre de tables créées était calculé par rapport au nombre maximal des joueurs du tournoi. Donc c'était :

            $T = (N_{max} - 1) / N_{table} + 1$

            ($T$ : Nombre de tables; $N_{max}$ : Nombre de joueurs maximal du tournoi; $N_{table}$ : Nombre de joueur maximal par table)

        \subsubsection{Déplacement de joueurs}
            Par défaut les nombres de joueurs des tables étaient pas obligé d'être identiques. Pour une table avec moins de joueurs la position du donneur tournait plus vite que cela d'une table avec plus de joueurs. De même un joueur de la table avec moins de joueurs payerait les blinds plus fréquemment. Donc le déplacement de joueurs était nécessaire pour équilibrer les nombres de joueurs de toutes les tables. Il a permis de rendre le jeu plus équitable pour tous les joueurs.

            Le déplacement des joueurs d'une certaine table ne pouvait être faire qu'après que le coup de jeu de la table était fini. Car il pouvait y avoir les joueurs éliminés tous les instant, nous calculait la distribution des joueurs chaque fois avant le déplacement. Le résultat était une liste de nombres de joueurs des tables comme un standard, soit le cas idéal après le déplacement. Si la table traitée avait plus de joueurs que le standard, les joueurs supplémentaires seraient inserés dans une table qui avait moins de joueur que son stantard.

            La distribution idéale des joueurs aux tables était calculée à la manière suivante :

            $T_{u} = (N - 1) / N_{table} + 1$

            $m = N / T_{u}$

            $T_{0} = N - m * T_{u}$

            ($N$ : Le nombre de joueurs survivant; $N_{table}$ : Nombre de joueur maximal par table)

            La fonction du nombre de tables par rapport au numéro de tables était :

            \begin{eqnarray}f(x)=
                \begin{cases}
                    m+1, &1\leqslant{}x\leqslant{}T_{0}\cr
                    m, &T_{0} + 1\leqslant{}x\leqslant{}T_{u}\cr
                    0, &T_{u} + 1\leqslant{}x\leqslant{}T
                \end{cases}
            \end{eqnarray}

            Après le déplacement un nouvel jeu serait créé pour les joueurs restants, les joueurs étirés seraient mis dans les listes d'attente de tables où il étaient déplacés.

        \subsubsection{Elévation de niveau}
            L'élévation de niveau était la partie plus importante d'un tounoi qui a distingué le tournoi et le jeu simple. Le niveau actuel du tournoi pouvait influer sur les blinds des jeu.

            Le niveau actuel était enregistré dans la table \textit{tournaments}. C'est-à-dire tous les tables partageaient cette information donc elles étaient toujours dans le même niveau.

            L'évévation de niveau était liée au temps, donc c'était le compteur qui était chargé. Deux nouveaux événements étaient ajoutés à la table \textit{timer\_events} : \textit{LEVEL\_BEGIN} et \textit{LEVEL\_END}

            L'événement \textit{LEVEL\_BEGIN} était créé en création du tournoi et chaque fois qu'un niveau a été fini. La tâche lié à ce événement était de faire commencer tous les jeux du tournoi. Pour assurer que le niveau actuel a été fini il faillait deux conditions, l'une était que le temps de la fin du tournoi était arrivé, l'autre était qu'il n'y avait pas de jeux en cours.

            L'événement \textit{LEVEL\_END} était créé justement après que la tâche \textit{LEVEL\_BEGIN} a été faite. Quand le compteur a trouvé ce événement dans la liste de tâches, il devait créer un nouvel événement \textit{LEVEL\_BEGIN} et augementer le niveau actuel dans la table \textit{tournaments} par un. Une seul exception était que s'il y avait des jeu en cours, le compteur ne ferait rien, car le niveau n'a pas été vraiment fini. La tâche était reportée à la moment que le denier jeu était fini (FIGURE 3.29).

            \begin{figure}[htb]
	            \centering\includegraphics[width=\linewidth]{./img/tournoi.pdf}
	            \caption{Le principe de l'élévation de niveau (en supposant qu'il y a trois tables du tournoi)}
            \end{figure}
        \subsubsection{Répartition d'argent}
            La façon de la répartition d'argent aux gagnants était un paramètre configuration pendant la création du tournoi. C'était une liste des pourcentage qui varient entre 0 et 100. Cette liste avait 100 éléments, c'est-à-dire nous pouvons définir la proportion de prix pour 100 premiers joueurs au maximum.

            Normalement nous avions :

            \begin{displaymath}
                \sum_{x=1}^{100} P(x) = 100
            \end{displaymath}

           (x : Position du joueur)

			Le prix était donc l'argent dans le pot du tournoi, soit la somme de tous les payments faits par les joueurs (inscription, recave et addon). Donc pour un joueur son prix personnel était :

			$G(x) = P(x) * S$

           (G : prix gagné; S : montant du pot du tournoi)

			En réel il y avait souvent des joueurs qui ont eu le même nombre de jetons à la fin. Ces deux joueurs auraient la même position dans le classement. Dans ce cas là ces joueurs partagerait ce qu'ils a mérité.

			Ici on présente un exemple de répartition d'argent pour les joueurs qui sont dans la même position :

			\begin{table}[htb]
				\centering
				\begin{tabular}{c|c|c|c|c}
					\hline
					Jetons du joueur & Classement faux & Part de prix faux & Classement vrai & Part de prix vrai\\
					\hline
					150 & 1 & 24\% & 1 & 33\%\\
					150 & 2 & 18\% & 1 & 33\%\\
					149 & 3 & 14\% & 3 & 11,67\%\\
					149 & 4 & 12\% & 3 & 11,67\%\\
					149 & 5 & 9\% & 3 & 11,67\%\\
					148 & 6 & 8\% & 6 & 8\%\\
					147 & 7 & 6\% & 7 & 6\%\\
					146 & 8 & 5\% & 8 & 0,9\%\\
					146 & 9 & 4\% & 8 & 0,9\%\\
					146 & 10 & 0\% & 8 & 0,9\%\\
					146 & 11 & 0\% & 8 & 0,9\%\\
					146 & 12 & 0\% & 8 & 0,9\%\\
					\hline
				\end{tabular}
			\end{table}

			Dans le programme nous ne distribuions pas immédiatement l'argent aux gagnants. Quand nous parcourions les gagnants, il était récompensé seulement quand le joueur dans la position suivante a eu moins de jetons que lui. Si non nous créerions un pot temporaire et une liste. L'argent gagné serait ajouté dans le pot et ce joueur serait mis dans la liste. A la fin l'argent dans le pot serait divisé en parties égales pour les joueurs dans la liste (FIGURE 3.29).

			\begin{figure}[htb]
	            \centering\includegraphics[width=0.6\linewidth]{./img/tourwin.pdf}
	            \caption{Répartion d'argent aux gagnants}
            \end{figure}
    \subsection{Résultats obtenus}
		Pour soumettre le projet à l'\textit{ARJEL} au plus vite pour l'obtension de licence, nous avons fini une version préliminaire qui manquait les détails sur l'affichage.

		L'autre problème était que le tournoi n'a jamais été testé avec un grand nombre de joueurs. En considérant la capacité de la machine, les tests étaient fait avec seulement trois joueurs. Mais trois joueurs étaient trop peu pour un tournoi -- suivant la règle du jeu, un tournoi avec seulement trois joueurs devait être annulé. Donc pour tester nous avons modifié le programme -- normalement il ne devait pas y avoir l'incohérence entre le produit final et celui testé, les résultats des tests étaient encore moins convaincants que les tests unitaires.
